Keep SMB rename verification off the UI thread#4611
Keep SMB rename verification off the UI thread#4611venkyqz wants to merge 1 commit intoTeamAmaze:release/4.0from
Conversation
There was a problem hiding this comment.
Pull request overview
This PR prevents a potential UI-thread network call during rename completion by limiting the post-rename exists(context) verification to SAF-backed targets only (DocumentFile/OTG), avoiding SMB (and other non-SAF) synchronous checks on the main thread.
Changes:
- Gate the post-rename
newFile.exists(context)probe behind a SAF/OTG-only predicate inMainActivityHelper. - Add a small helper (
shouldVerifyRenameWithExists) encapsulating the gating decision. - Add a focused unit test covering the SAF vs non-SAF decision behavior.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| app/src/main/java/com/amaze/filemanager/utils/MainActivityHelper.java | Skips UI-thread exists(context) verification for SMB/non-SAF rename completion; keeps it for SAF/OTG where the workaround is needed. |
| app/src/test/java/com/amaze/filemanager/utils/MainActivityHelperTest.java | Adds regression coverage for the SAF/OTG-only verification decision. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1bbd4da to
a036ec2
Compare
The rename completion path in MainActivityHelper re-checked success by calling newFile.exists(context) on the UI thread because SAF-backed renames can report false negatives. For SMB targets that fallback routes into HybridFile.exists() and performs synchronous network I/O on the main thread. Limit the fallback probe to SAF-backed targets and cover it with a focused regression test. Constraint: Preserve the post-rename verification workaround for SAF-backed rename targets Rejected: Change HybridFile.exists() semantics for all SMB callers | too broad and would affect background operations that legitimately rely on it Confidence: high Scope-risk: narrow Directive: Keep rename completion fallbacks off the UI thread for remote backends; only use exists(context) as a SAF-specific verification path Tested: ./gradlew :app:testFdroidDebugUnitTest --tests com.amaze.filemanager.utils.MainActivityHelperTest -x kaptFdroidDebugUnitTestKotlin Tested: ./gradlew :app:compileFdroidDebugJavaWithJavac Tested: ./gradlew :app:compileFdroidDebugUnitTestJavaWithJavac -x kaptFdroidDebugUnitTestKotlin Not-tested: Full :app:testFdroidDebugUnitTest (blocked by existing kaptFdroidDebugUnitTestKotlin failure in unrelated tests referencing missing ShadowMultiDex)
a036ec2 to
015f7cf
Compare
| * instead of merely looking at the return value | ||
| */ | ||
| if (b || newFile.exists(context)) { | ||
| if (b |
There was a problem hiding this comment.
This doesn't fix the issue (exists running on main thread) and seems incredibly easy to break if the implementation of Operations.rename changes (by changing how otg is handled or using DocumentFile for other file types). To fix the issue, the exists check should probably be moved to Operations.rename.
Problem:
The rename completion path in
MainActivityHelpermay callnewFile.exists(context)on the UI thread after a rename attempt. For SMB targets that falls intoHybridFile.exists()and performs synchronousSmbFile.exists()network I/O on the main thread.Root cause:
The post-rename existence probe was added as a SAF workaround because
DocumentFile.renameTo()can report false even when the rename succeeds, but the fallback was applied uniformly to all backends.Fix:
Limit the post-rename
exists(context)verification to SAF-backed targets (DOCUMENT_FILEandOTG) and skip that UI-thread probe for SMB and other non-SAF modes.Closes #4610